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Examiner: Nathan Hillary 



RECEIVED 
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Technology Center 2100 



TELPHONE INTERVIEW AGENDA 



Honorable Commissioner of 
Patents and Trademarks 
Washington, D.C. 20231 

Dear Sir: 



In preparation for the telephone interview on February 26 th at 2pm EST, Applicants^are 
submitting this proposed interview agenda. In addition, to facilitate the discussion Applicants 
are submitting pages 4 and 5 from the specification for discussion. 

In the outstanding Office Action, the Examiner rejected claims 1-3, 7, 8-10, 14, 15-17? 
and 21 under 35 U.S.C. § 103(a) as obvious in view of U.S. Patent No. 6,532,463 to Robbins et 
al. (hereinafter "Robbins"), a Research Disclosure publication 4231 1 1 from IBM (hereinafter 
"Research Disclosure"), and U.S. Patent No. 6,125,391 to Meltzer et al. (hereinafter "Meltzer"). 



REMARKS 

Applicants would like to discuss where objective teachings that suggest the claimed 
subject matter of claims 1, 8, and 15 are specifically taught in the prior art. See In re Fine, 837 
F.2d 1071, 1074, 5 USPQ2d 1596, 1598 (Fed. Cir. 1988). 

Specifically, Applicants would like to discuss where the prior art teaches "receiving a 
document comprising an IMS transaction definition encoded in XML.. . for decoding the IMS 
transaction definition; and providing the decoded IMS transaction definition to the IMS" 
(claim 1, emphasis added). In particular, Applicants find no reference in any of the prior art to 
IMS much less to an "IMS transaction definition" which is specifically recited in claim 1. 
Applicants submit that such clear and specific language limits the scope of the present invention 
to steps involving IMS transaction definitions. Applicants submit that giving this term its "plain 
meaning" clearly defines the invention and places the invention outside the scope of the prior art. 
See In reZletz, 893 F.2d 319, 321, 13 USPQ2d 1320, 1322 (Fed. Cir. 1989), MPEP §2111.01. 

Applicants would like to discuss how prior art that does not mention IMS can rise to the 
level of a combination of prior art references that teaches or suggests all the claim limitations as 
required for a rejection under 35 USC § 103(a). See MPEP § 2142. In particular, the prior art 
discusses web-enabled access to mainframe data. Applicants would like to discuss how an IMS 
transaction definition deals with management and operation of the EMS system in servicing 
transactions, not direct access to mainframe data. 

Finally, Applicants would like to discuss where in the Robbins, Research Disclosure, and 
Meltzer references one of ordinary skill in the art would be motivated to make the combination 
suggested by the Examiner. Applicants would like to discuss how one with a computer science 
or electrical engineering degree, one of ordinary skill in the art, would interpret the cited prior art. 
Furthermore, Applicants would like to understand why one of ordinary skill in the art would 
make the combination suggested by the Examiner when the combination lacks such an important 
element, the IMS transaction definition. 



If any issues remain that can be resolved by a telephone conversation, the Examiner 
respectfully requested to contact the undersigned. 



Date: February 18.2004 
8 E. Broadway, Suite 600 
Salt Lake City, UT84111 
Telephone (801)994-4646 
Fax (801)531-1929 



Respectfully submitted, 




David J. McKenzie 
Reg. No. 46,919 
Attorney for Applicant 
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IMSCTL 26 logs all transactions in order to provide the capability of undoing non- 
committed transactions in the event of a system failure. 

In addition, every time IMSCTL 26 receives a message from a terminal 28, it 
schedules an application 18 to process the message. IMSCTL 26 identifies the 
desired application 18 and puts the message in the application's message queue 30. 
The application 18 processes the requests in its message queue 30 and responds to 
the originating terminal 28 by placing the response in the terminal's message queue 
32. 

As illustrated in Figure 4, an IMS 10 obtains all of its information about the 
structure and behavior of its components (applications, databases, transactions, etc.) 
from macro statements 34 (hereinafter "macros"). Certain macros 34 are referred 
to as "transaction definitions" 35 because they define how transactions are 
processed. 

For example, as shown in Figure 4, an application (APPLCTN) macro 36 
defines the behavior of a particular IMS application 18. An APPLCTN macro 36 
exists for each application 18 in the IMS 10, and defines, for example, the 
application's name, resource requirements, and appearance. 

An APPLCTN macro 36 is followed by a zero or more (TRANSACT) macros 
38, which define the various transactions applicable to the application 18. A 
TRANSACT macro 38 specifies the appearance of a transaction to be performed by 
an application 18, identifying whether the transaction is IMS exclusive, IMS Fast 
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Path potential or IMS Fast Path exclusive. Furthermore, a TRANSACT macro 38 
specifies the transaction code that causes the application 18 named in the APPLCTN 
macro 36 to be scheduled for execution in an IMS processing region. 

Currently, IMS is only capable of processing transactions previously defined 
by the APPLCNT and TRANSACT macros 36, 38. A user may not initiate arbitrary 
transactions, such queries of the database 14, that have not been previously defined. 
Moreover, in order to change the above-described macros, one must initiate a 
process called "system generation," which necessitates shutting down the IMS 10 
for a period of time. 

In addition, the above-described IMS macros 36, 38 have a proprietary 
format, which is a detriment in interfacing with remotely located systems from 
different vendors. Currently, the dominant Internet format is the HyperText 
Markup Language (HTML), a variant of the extensible Markup Language (XML). 
Providing a technique for delivering IMS transactions definitions to an IMS 10 using 
interchangeable documents, such as XML documents, would be a first step in being 
able to initiate arbitrary IMS transactions over the Internet. 

Accordingly, what is needed is a system and method for representing IMS 
transaction definitions in an interchangeable format, such as XML. What is also 
needed is a system and method for communicating with an IMS 10 using XML 
documents. In addition, what is needed is a system and method for creating a 
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